nodesという名前だと、nodeの配列に感じて、nodeWithDepthの配列だというのは誤解を生むように思えました。

ありがとうございます。

読む時に違和感を感じないよう nodesWithDepth などのほうが適切そうですね。

このテクニック知らなかったので勉強になりました！メモリリークが起きないようにしているんですね

これよく知らなかったのですが、ここの SliceTricks に
https://go.dev/wiki/SliceTricks

NOTE If the type of the element is a pointer or a struct with pointer fields, which need to be garbage collected, the above implementations of Cut and Delete have a potential memory leak problem: some elements with values are still referenced by slice a’s underlying array, just not “visible” in the slice. Because the “deleted” value is referenced in the underlying array, the deleted value is still “reachable” during GC, even though the value cannot be referenced by your code. If the underlying array is long-lived, this represents a leak. The following code can fix this problem:

とありました。

はい、Go のスライスは underlying array を持つ構造になっているのでこういうテクニックが必要になるのでしょうね。

みなさまコメントありがとうございます。

おそらく私が最初にこのやり方を知ったのは優先度付きキューの実装例に同様の記載があったことだったかと思います。
記載いただいた通りスライスの構造に由来する処理と理解しています。

https://pkg.go.dev/container/heap

// don't stop the GC from reclaiming the item eventually

自分ならpanicしちゃうかなあと思いました。

ありがとうございます。

一般的には error を返すインターフェースにすると思うので、ちょっと書きづらいところではあります。
この練習会では到達不能なコードには panic を使うのが assert 的な意図も伝えられレビュワーにとっては違和感なさそうなので、次回からはその方針にしようと思いました。
（実務では panic はほぼ使わないので、書くのに躊躇する感じでした）